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DETAILED ACTION 

This office action is responsive to communications filed on February 25, 2010. 
Claims 1,9, 19 and 31 have been amended. Claims 1-5, 8-15 and 18-39 are pending in 
the application. 

Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims 1-4, 6, 8-14, 16, 18-24, 26-30, 31-37 and 39 are rejected under 35 
U.S.C. 103(a) as being unpatentable over US 5,261,085 (hereinafter, '085) in view of 
Paxos Made Simple (hereinafter, Paxos). 

Regarding Claim 1 , '085 teaches a method for selecting a value in a distributed 
computing system using a fault tolerant consensus algorithm, the method comprising: 

receiving at a first computing device from a first client a first message comprising 
a first proposed value and a first client identifier corresponding to the first client ("One of 
the processes in the network is designated as a leader, and it sends ballots with 
proposed commands to the other processes" - See Col. 3, lines 14-16; "The preliminary 
protocol for conducting a single ballot initiated by process p is follows"- See Col. 4, 
lines 56-57); 
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provisionally voting at the computing device for the first proposed value ("In each 
ballot, a process has the choice of either voting for the proposed command or not 
voting"- See Col. 3, lines 16-18); 

transmitting from the first computing device a first indication of the provisional 
voting for the first proposed value to one or more devices {"MaxVote(b,q,l3)dec is the vote 
with the largest ballot number less than b among all the votes cast by process q, or null q 
if process q did not vote in any ballot numbered less than b. The leader obtains 
MaxVote(b,q,(3)dec from each process q by an exchange of messages"- See Col. 4, 
lines 51-55); and 

transmitting from the computing device a first result of the voting for the first 
proposed value to the first client ("A process q responds to the receipt of the 
NextBallot(b) message by sending a LastVote(b,v) message to p"- See Col. 4, lines 
61-62). 

'085 teaches clients having identifiers and determining if a second identifier is 
more dominant than a first identifier ("One suitable method of choosing the leader is to 
select the process with the highest identification number"- See Col. 8, lines 33-34). 
'085 does not explicitly teach that the voting for the first proposed value, the transmitting 
the first indication of the voting for the first proposed value, and the transmitting the first 
result are not performed if a second message had previously been received at the 
computing device from a second client, the second message comprising a second 
proposed value and a second client identifier corresponding to a second client, the 
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second identifier being more dominant than the first client identifier and the second 
proposed value having been previously provisionally voted for. 

However, Paxos teaches a first client, a second client and a third client proposing 
values ("/Assume a collection of processes that can propose values"- See p. 1 ). Paxos 
also discloses that a proposal numbered n is "accepted" by an acceptor if and only if the 
acceptor has not already accepted a request having a number greater (more dominant) 
than n ("A proposer sends a proposed value to a set of acceptors. An acceptor may 
accept the proposed value. The value is chosen when a large enough set of acceptors 
have accepted it"- See p. 2, lines 13-15; "An acceptor can accept a proposal numbered 
n iff it has not responded to a prepare request having a number greater than n"- See p. 
5, lines 10-1 1 ). Paxos describes an acceptor accepting a proposed value in a fashion 
similar to the way '085 describes voting for a proposed value. Thus, a second proposed 
value will be accepted if it has an identifier greater than the identifier of a first proposed 
value, and will not be accepted if it has an identifier less than the identifier of the first 
proposed value. Similarly, a third proposed value will be accepted if it has an identifier 
greater than the identifiers of a first and second proposed value, and will not be 
accepted if it has an identifier less than the identifiers of either the first or second 
proposed value, since a proposal is only accepted if a higher-numbered proposal has 
not already been accepted. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the method of selecting a value disclosed by '085 to 
include not voting for a first proposed value, not transmitting a first indication of the 
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voting for the first proposed value, and not transmitting a first result if a second or third 
proposed value was proposed by a second or third client having a second or third client 
identifier that is more dominant than the first client identifier and the second or third 
proposed value was previously voted for. One of ordinary skill could easily apply the 
principle of comparing proposal numbers shown by Paxos to the teachings of '085 to 
end up with comparing identifiers of a first, second and third client, each of whom 
generates a proposal. Paxos describes a number of "safety requirements" for 
guaranteeing consensus in a distributed system on p. 1, lines 18-23. The step of 
comparing proposal numbers along with the respective outcomes of the comparison is 
necessary in order to satisfy the safety properties which guarantee consensus (See p. 
5, lines 13-14). 

Regarding Claim 2, '085 further teaches that the first proposed value comprises a 
first function, and wherein the voting for the first proposed value comprises provisionally 
executing the first function in the first system step (To be issued, a command must be 
voted for by a majority of the processes in the system. Each issued command is stored 
by each of the processes in the majority set which voted for it"- See Col. 2, lines 37- 
40). 

Regarding Claim 3, '085 further teaches the voting for the first proposed value 
comprising changing a previous vote for the second proposed value if the second 
proposed value was previously voted for and if the second client identifier is less 
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dominant than the first client identifier ("the receipt of a NextBallot(b) message by a 
process q in step 2 may set nextbal(q) to a value that prevents q from voting in step 4 
for any previously initiated ballot"- See Col. 7, lines 31-33). 

Regarding Claim 4, '085 further teaches the first proposed value comprising a 
first function identified by a first function identifier ("one of the processes send a 
message containing its identification number to every other process" - See Col. 8, lines 
36-37), and wherein the voting for the first proposed value comprises executing the first 
function in the first system step ("Steps 1-4 thus contain the protocol for initiating a 
ballot and voting on it. In step 5, the results of the balloting are determined, and in step 
6 the command is declared to be issued"- See Col. 5, lines 59-62) unless the first 
function identifier is equivalent to a second function identifier that identifies a second 
function, wherein the second function was executed in a second system step that 
preceded the first system step ("Receiving multiple copies of a message can cause an 
action to be repeated. Except in step 3, performing the action a second time has no 
effect. For example, sending several Voted(b,q) messages in step 4 has the same effect 
as sending just one. The repetition of step 3 is prevented by using the entry made in 
stable storage when it is executed. Thus, the consistency condition is maintained even if 
the same message is received several times"- See Col. 5, lines 50-58). 



Regarding Claim 6, '085 further teaches: 
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receiving a message ("The network can be of any suitable type or configuration 
which permits messages to be sent between any two computers on the network"- See 
Col. 3, lines 9-11), wherein the message is part of a fault tolerant consensus algorithm 
("This invention pertains generally to distributed computing systems and, more 
particularly, to a distributed system and method utilizing a state machine approach and 
having the ability to continue working despite the occurrence of a fault such as a 
processor stopping or running slowly"- See Col. 1 , lines 8-13); 

ignoring additional proposed values from the first client ("For example, a process 
q in the majority set can ignore a NextBallot(b) message"- See Col. 5, lines 41-42); and 

participating in the fault tolerant consensus algorithm ("consistency is maintained 
despite the failure of any number of processes and communication paths" -See Col. 
10, lines 64-66). 

Regarding Claim 8, '085 further teaches: 

transmitting one or more polling messages to initiate a fault tolerant consensus 
algorithm ("The preliminary protocol for conducting a single ballot initiated by process p 
is follows: .... 1. Process p (the leader) chooses a new ballot number b and sends a 
NextBallot(b) message to some set of processes" - See Col. 4, lines 56-60); 

receiving one or more vote indication messages in response to the one or more 
polling messages ("2. A process q responds to the receipt of the NextBallot(b) message 
by sending a LastVote(b,v) message to p"- See Col. 4, lines 61 -62); and 
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selecting, as a third proposed value, any value if the one or more vote indication 
messages indicate that at least one device has not previously voted or if the one or 
more vote indication messages indicate two or more different possibly selected 
proposed values {"any command for which one of the processes has previously voted 
but does not have a command number is broadcast as a proposed command in a new 
ballot"- See Col. 2, lines 48-51 ), wherein a possibly selected proposed value was 
previously voted for by a device and was proposed by a client having a most dominant 
client identifier among all clients whose proposals were received by the device, and 
wherein further the third proposed value is proposed using the fault tolerant consensus 
algorithm ("The selection requirement is then satisfied by having one of the processes 
send a message containing its identification number to every other process every T-11 
msec, for some suitable choice of T"- See Col. 8, lines 35-38). 

Claim 9 is rejected based on reasoning similar to Claim 1 . 

Regarding Claim 10, '085 further teaches that the first proposed value comprises 
a first function, and wherein the voting for the first proposed value comprises 
provisionally executing the first function in the first system step (To be issued, a 
command must be voted for by a majority of the processes in the system. Each issued 
command is stored by each of the processes in the majority set which voted for it" - See 
Col. 2, lines 37-40). 
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Regarding Claim 1 1 , '085 further teaches the voting for the first proposed value 
comprising changing a previous vote for the second proposed value if the second 
proposed value was previously voted for and if the second client identifier is less 
dominant than the first client identifier ("the receipt of a NextBallot(b) message by a 
process q in step 2 may set nextbal(q) to a value that prevents q from voting in step 4 
for any previously initiated ballot"- See Col. 7, lines 31-33). 

Regarding Claim 12, '085 further teaches the second proposed value comprising 
a second proposed function, and wherein the changing the previous vote comprises 
undoing a previous execution of the second proposed function ("a process has the 
option not to vote, even if casting a vote is not precluded by a previous LastVote 
message"- See Col. 5, lines 38-40). 

Regarding Claim 13, '085 further teaches the second proposed value comprises 
a second proposed function, and wherein the changing the previous vote comprises 
allowing a previous provisional execution of the second proposed function to expire 
("the initiation of a new ballot can prevent any previously initiated ballot from 
succeeding"- See Col. 7, lines 34-35). 

Regarding Claim 14, '085 further teaches the first proposed value comprising a 
first function identified by a first function identifier ("one of the processes send a 
message containing its identification number to every other process" - See Col. 8, lines 
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36-37), and wherein the voting for the first proposed value comprises executing the first 
function in the first system step {"Steps 1-4 thus contain the protocol for initiating a 
ballot and voting on it. In step 5, the results of the balloting are determined, and in step 
6 the command is declared to be issued" -See Col. 5, lines 59-62) unless the first 
function identifier is equivalent to a second function identifier that identifies a second 
function, wherein the second function was executed in a second system step that 
preceded the first system step ("Receiving multiple copies of a message can cause an 
action to be repeated. Except in step 3, performing the action a second time has no 
effect. For example, sending several Voted(b,q) messages in step 4 has the same effect 
as sending just one. The repetition of step 3 is prevented by using the entry made in 
stable storage when it is executed. Thus, the consistency condition is maintained even if 
the same message is received several times"- See Col. 5, lines 50-58). 

Regarding Claim 16, '085 further teaches: 

receiving at a computing device a message {"The network can be of any suitable 
type or configuration which permits messages to be sent between any two computers 
on the network"- See Col. 3, lines 9-1 1 ), wherein the message is part of a fault tolerant 
consensus method ("This invention pertains generally to distributed computing systems 
and, more particularly, to a distributed system and method utilizing a state machine 
approach and having the ability to continue working despite the occurrence of a fault 
such as a processor stopping or running slowly"- See Col. 1, lines 8-13); 
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ignoring additional proposed values from the first client ("For example, a process 
q in the majority set can ignore a NextBallot(b) message"- See Col. 5, lines 41-42); and 

participating in the fault tolerant consensus method ("consistency is maintained 
despite the failure of any number of processes and communication paths" -See Col. 
10, lines 64-66). 

Regarding Claim 18, '085 further teaches: 

transmitting from the computing device one or more polling messages to initiate a 
fault tolerant consensus method ("The preliminary protocol for conducting a single ballot 
initiated by process p is follows: .... 1. Process p (the leader) chooses a new ballot 
number b and sends a NextBallot(b) message to some set of processes" - See Col. 4, 
lines 56-60); 

receiving at the computing device one or more vote indication messages in 
response to the one or more polling messages ("2. A process q responds to the receipt 
of the NextBallot(b) message by sending a LastVote(b,v) message to p"- See Col. 4, 
lines 61-62); and 

selecting, as a third proposed value, any value if the one or more vote indication 
messages indicate that at least one device has not previously voted or if the one or 
more vote indication messages indicate two or more different possibly selected 
proposed values ("any command for which one of the processes has previously voted 
but does not have a command number is broadcast as a proposed command in a new 
ballot"- See Col. 2, lines 48-51), wherein a possibly selected proposed value was 
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previously voted for by a device and was proposed by a client having a most dominant 
client identifier among all clients whose proposals were received by the device, and 
wherein further the third proposed value is proposed using the fault tolerant consensus 
method {"The selection requirement is then satisfied by having one of the processes 
send a message containing its identification number to every other process every T-11 
msec, for some suitable choice of T"- See Col. 8, lines 35-38). 

Claim 19 is rejected based on reasoning similar to Claim 1 . 

Regarding Claim 20, '085 further teaches the first proposed value comprising a 
first function, and wherein the voting for the first proposed value comprises provisionally 
executing the first function in the first system step (To be issued, a command must be 
voted for by a majority of the processes in the system. Each issued command is stored 
by each of the processes in the majority set which voted for it"- See Col. 2, lines 37- 
40). 

Regarding Claim 21 , '085 further teaches the voting for the first proposed value 
comprising changing a previous vote for the second proposed value if the second 
proposed value was previously voted for and if the second client identifier is less 
dominant than the first client identifier ("the receipt of a NextBallot(b) message by a 
process q in step 2 may set nextbal(q) to a value that prevents q from voting in step 4 
for any previously initiated ballot"- See Col. 7, lines 31-33). 
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Regarding Claim 22, '085 teaches the second proposed value comprising a 
second proposed function, and wherein the changing the previous vote comprises 
undoing a previous execution of the second proposed function ("a process has the 
option not to vote, even if casting a vote is not precluded by a previous LastVote 
message"- See Col. 5, lines 38-40). 

Regarding Claim 23, '085 further teaches the second proposed value comprising 
a second proposed function, and wherein the changing the previous vote comprises 
allowing a previous provisional execution of the second proposed function to expire 
("the initiation of a new ballot can prevent any previously initiated ballot from 
succeeding"- See Col. 7, lines 34-35). 

Regarding Claim 24, '085 teaches the first proposed value comprising a first 
function identified by a first function identifier ("one of the processes send a message 
containing its identification number to every other process" - See Col. 8, lines 36-37), 
and wherein the voting for the first proposed value comprises executing the first function 
in the first system step ("Steps 1-4 thus contain the protocol for initiating a ballot and 
voting on it. In step 5, the results of the balloting are determined, and in step 6 the 
command is declared to be issued" -See Col. 5, lines 59-62) unless the first function 
identifier is equivalent to a second function identifier that identifies a second function, 
wherein the second function was executed in a second system step that preceded the 
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first system step ("Receiving multiple copies of a message can cause an action to be 
repeated. Except in step 3, performing the action a second time has no effect. For 
example, sending several Voted(b,q) messages in step 4 has the same effect as 
sending just one. The repetition of step 3 is prevented by using the entry made in stable 
storage when it is executed. Thus, the consistency condition is maintained even if the 
same message is received several times"- See Col. 5, lines 50-58). 

Regarding Claim 26, '085 further teaches: 

ignoring additional proposed values from the first client ("For example, a process 
q in the majority set can ignore a NextBallot(b) message"- See Col. 5, lines 41-42); and 

participating in a fault tolerant consensus method ("consistency is maintained 
despite the failure of any number of processes and communication paths" -See Col. 
10, lines 64-66); and 

wherein the network interface performs further steps comprising: 

receiving a message ("The network can be of any suitable type or configuration 
which permits messages to be sent between any two computers on the network"- See 
Col. 3, lines 9-11), wherein the message is part of the fault tolerant consensus method 
("This invention pertains generally to distributed computing systems and, more 
particularly, to a distributed system and method utilizing a state machine approach and 
having the ability to continue working despite the occurrence of a fault such as a 
processor stopping or running slowly"- See Col. 1 , lines 8-13). 
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Regarding Claim 27, '085 further teaches the participating in the fault tolerant 
consensus method comprising transmitting a possibly selected proposed value if a 
proposed value was previously voted for, wherein the possibly selected proposed value 
was previously voted for and was proposed by a client having a most dominant client 
identifier among all clients who proposed values to the computing device for a current 
system step {"As part of this procedure, any command for which one of the processes 
has previously voted but does not have a command number is broadcast as a proposed 
command in a new ballot"- See Col. 2, lines 48-51 ). 

Regarding Claim 28, '085 further teaches: 

selecting, as a third proposed value, any value if one or more vote indication 
messages indicate that at least one device has not previously voted or if the one or 
more vote indication messages indicate two or more different possibly selected 
proposed values ("any command for which one of the processes has previously voted 
but does not have a command number is broadcast as a proposed command in a new 
ballot"- See Col. 2, lines 48-51 ), 

wherein a possibly selected proposed value was previously voted for by a device 
and was proposed by a client having a most dominant client identifier among all clients 
whose proposals were received by the device, and wherein further the third proposed 
value is proposed using the fault tolerant consensus method ("The selection 
requirement is then satisfied by having one of the processes send a message 
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containing its identification number to every other process every T-11 msec, for some 
suitable choice of T" - See Col. 8, lines 35-38); and 

wherein the network interface performs further steps comprising: 
transmitting one or more polling messages to initiate the fault tolerant consensus 
algorithm ("The preliminary protocol for conducting a single ballot initiated by process p 
is follows: .... 1. Process p (the leader) chooses a new ballot number b and sends a 
NextBallot(b) message to some set of processes" - See Col. 4, lines 56-60); and 

receiving the one or more vote indication messages in response to the one or 
more polling messages ("2. A process q responds to the receipt of the NextBallot(b) 
message by sending a LastVote(b,v) message to p" - See Col. 4, lines 61-62). 

Regarding Claim 29, '085 further teaches the operating as part of the distributed 
computing system comprising operating as a client of the distributed computing system 
("a distributed system 11 in which the invention is employed has a set of computers 12 
which are connected together by a network 13"- See Col. 3, lines 1 -3). 

Regarding Claim 30, '085 further teaches the distributed computing system being 
comprised of devices that are also clients of the distributed computing system ("a 
distributed system 11 in which the invention is employed has a set of computers 12 
which are connected together by a network 13"- See Col. 3, lines 1-3). 
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Regarding Claim 31 , '085 teaches a conflict tolerant message delay reducing 
consensus method for use in computing environment comprising at least one dedicated 
client device and a distributed computing system implemented by one or more devices, 
the conflict tolerant message delay reducing consensus method comprising: 

transmitting one or more proposed values from one or more clients, each of the 
one or more proposed values being transmitted in a message comprising one of the one 
or more proposed values and a client identifier corresponding to one of the one or more 
clients ("One of the processes in the network is designated as a leader, and it sends 
ballots with proposed commands to the other processes" - See Col. 3, lines 14-16); 

voting, at one or more of the one or more devices implementing the distributed 
computing system, for a proposed value from among the one or more proposed values 
("In each ballot, a process has the choice of either voting for the proposed command or 
not voting"- See Col. 3, lines 16-18), wherein the proposed value was proposed by a 
client having a most dominant client identifier from among the one or more clients 
proposing values ("One suitable method of choosing the leader is to select the process 
with the highest identification number"- See Col. 8, lines 33-34); 

transmitting to one or more of the one or more devices implementing the 
distributed computing system an indication of the vote for the proposed value 
("MaxVote(b,q,P)dec is the vote with the largest ballot numberless than b among all the 
votes cast by process q, or null q if process q did not vote in any ballot numbered less 
than b. The leader obtains MaxVote(b,q,(3)dec from each process q by an exchange of 
messages" - See Col. 4, lines 51-55); and 
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transmitting, to the client having the highest client identifier, a result of the vote 
for the proposed value {"The preliminary protocol for conducting a single ballot initiated 
by process p is follows"- See Col. 4, lines 56-57; "A process q responds to the receipt 
of the NextBallot(b) message by sending a LastVote(b,v) message to p"- See Col. 4, 
lines 61-62). 

'085 teaches clients having identifiers and determining if a second identifier is 
more dominant than a first identifier ("One suitable method of choosing the leader is to 
select the process with the highest identification number"- See Col. 8, lines 33-34). 
'085 does not explicitly teach that the voting for the first proposed value, the transmitting 
the first indication of the voting for the first proposed value, and the transmitting the first 
result are not performed if a second message is received at the computing device from 
a second client, the second message comprising a second proposed value and a 
second client identifier corresponding to a second client, the second identifier being 
more dominant than the first client identifier and the second proposed value having 
been previously voted for. 

However, Paxos teaches a first client and a second client proposing values 
("Assume a collection of processes that can propose values" -See p. 1). Paxos also 
discloses that a proposal numbered n is "accepted" by an acceptor if and only if the 
acceptor has not already accepted a request having a number greater (more dominant) 
than n ("A proposer sends a proposed value to a set of acceptors. An acceptor may 
accept the proposed value. The value is chosen when a large enough set of acceptors 
have accepted it"- See p. 2, lines 13-15; "An acceptor can accept a proposal numbered 



Application/Control Number: 10/750,601 Page 19 

Art Unit: 2446 

n iff it has not responded to a prepare request having a number greater than n" - See p. 
5, lines 1 0-1 1 ). Paxos describes an acceptor accepting a proposed value in a fashion 
similar to the way '085 describes voting for a proposed value. It would have been 
obvious to one of ordinary skill in the art at the time the invention was made to modify 
the method of selecting a value disclosed by '085 to include not voting for a first 
proposed value, not transmitting a first indication of the voting for the first proposed 
value, and not transmitting a first result if a second proposed value was proposed by a 
second client having a second client identifier that is more dominant than the first client 
identifier and the second proposed value was previously voted for. One of ordinary skill 
could easily apply the principle of comparing proposal numbers shown by Paxos to the 
teachings of '085 to end up with comparing identifiers of a first and second client, each 
of whom generates a proposal. Paxos describes a number of "safety requirements" for 
guaranteeing consensus in a distributed system on p. 1, lines 18-23. The step of 
comparing proposal numbers along with the respective outcomes of the comparison is 
necessary in order to satisfy the safety properties which guarantee consensus (See p. 
5, lines 13-14). 

Regarding Claim 32, '085 further teaches the one or more devices implementing 
the distributed computing system also acting as clients of the distributed computing 
system ("a distributed system 11 in which the invention is employed has a set of 
computers 12 which are connected together by a network 13"- See Col. 3, lines 1-3). 
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Regarding Claim 33, '085 further teaches the dedicated client device being 
identified by a least dominant client identifier ("The selection requirement is then 
satisfied by having one of the processes send a message containing its identification 
number to every other process" - See Col. 8, lines 35-37). 

Regarding Claim 34, '085 further teaches determining that the distributed 
computing system has selected the proposed value when each of the one or more 
devices implementing the distributed computing system has voted for the proposed 
value ("In order for a ballot to succeed and a command to be issued, a majority set of 
the processes in the system must vote for it"- See Col. 3, lines 18-20). 

Regarding Claim 35, '085 further teaches the proposed value comprising a 
function, and wherein the voting for the proposed value comprises provisionally 
executing the function in a system step (To be issued, a command must be voted for 
by a majority of the processes in the system. Each issued command is stored by each 
of the processes in the majority set which voted for it"- See Col. 2, lines 37-40). 

Regarding Claim 36, '085 teaches the voting for the proposed value comprising 
changing a previous vote if the previous vote was for a previously proposed value, 
proposed by a previous client having a client identifier that is less dominant than the 
client proposing the proposed value ("the receipt of a NextBallot(b) message by a 
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process q in step 2 may set nextbal(q) to a value that prevents q from voting in step 4 
for any previously initiated ballot"- See Col. 7, lines 31-33). 

Regarding Claim 37, '085 teaches ending the conflict tolerant message delay 
reducing consensus algorithm and commencing a fault tolerant consensus algorithm if a 
failure is detected {"The invention provides a system and method for implementing a 
distributed state machine in which consistency is maintained despite the failure of any 
number of processes and communication paths"- See Col. 2, lines 22-25). 

Regarding Claim 39, '085 further teaches identifying a possibly selected 
proposed value, wherein the possibly selected proposed value is any value if at least 
one of the one or more devices implementing the distributed computing system did not 
previously vote ("any command for which one of the processes has previously voted but 
does not have a command number is broadcast as a proposed command in a new 
ballot"- See Col. 2, lines 48-51). 

3. Claims 5, 1 5 and 25 are rejected under 35 U.S.C. 1 03(a) as being unpatentable 
over '085 in view of Paxos and further in view of US 2003/0227392 (hereinafter, '392). 

Regarding Claim 5, '085 in view of Paxos teaches the method of Claim 1 . '085 
and Paxos do not explicitly teach the first proposed value comprising a first idempotent 
function, and wherein the voting for the first proposed value comprises executing the 
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first idempotent function in the first system step even if the first idempotent function is 
equivalent to a second idempotent function that was executed in a second system step 
that preceded the first system step. 

However, '392 discloses the use of idempotent operations {"In general it is not 
easy to be certain which events were acted upon and which were lost. Furthermore, 
there is no inherent ordering of the processing of events through the real time semantics 
section 1630 and the core 1610. Replaying sufficient events to cover the largest 
possible loss works, provided all processing is idempotent and order independent" - 
See [0263]) so that a first function idempotent function may be executed even though 
an equivalent idempotent function has been executed previously {"If this condition is 
met, the semantics of the operations invoked 2060 are such that if events are 
processed in different orders or if the same event is processed more than once, the 
ultimate system state will be identical"- See [0263]). 

It would have been obvious to one of ordinary skill at the time the invention was 
made to use idempotent functions with the distributed computing method taught by '085 
and Paxos. '085 and Paxos generally disclose distributed computing systems where 
commands (functions) are distributed for execution by different machines on a network. 
'392 teaches that when idempotent functions are used, if the same function is 
processed (executed) more than once, then the end result will be identical (See [0263]). 

Regarding Claim 15, '085 in view of Paxos teaches the computer-readable 
medium of Claim 9. '085 and Paxos do not explicitly teaches the first proposed value 
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comprising a first idempotent function, and wherein the voting for the first proposed 
value comprises executing the first idempotent function in the first system step even if 
the first idempotent function is equivalent to a second idempotent function that was 
executed in a second system step that preceded the first system step. 

However, '392 discloses the use of idempotent operations ("In general it is not 
easy to be certain which events were acted upon and which were lost. Furthermore, 
there is no inherent ordering of the processing of events through the real time semantics 
section 1630 and the core 1610. Replaying sufficient events to cover the largest 
possible loss works, provided all processing is idempotent and order independent" - 
See [0263]) so that a first function idempotent function may be executed even though 
an equivalent idempotent function has been executed previously ("If this condition is 
met, the semantics of the operations invoked 2060 are such that if events are 
processed in different orders or if the same event is processed more than once, the 
ultimate system state will be identical" - See [0263]). 

It would have been obvious to one of ordinary skill at the time the invention was 
made to use idempotent functions with the distributed computing method taught by '085 
and Paxos for the same reasons as those given with respect to Claim 5. 

Regarding Claim 25, '085 in view of Paxos teaches the computing device of 
Claim 19. '085 and Paxos do not explicitly teaches the first proposed value comprising 
a first idempotent function, and wherein the voting for the first proposed value 
comprises executing the first idempotent function in the first system step even if the first 



Application/Control Number: 10/750,601 Page 24 

Art Unit: 2446 

idempotent function is equivalent to a second idempotent function that was executed in 
a second system step that preceded the first system step. 

However, '392 discloses the use of idempotent operations ("In general it is not 
easy to be certain which events were acted upon and which were lost. Furthermore, 
there is no inherent ordering of the processing of events through the real time semantics 
section 1630 and the core 1610. Replaying sufficient events to cover the largest 
possible loss works, provided all processing is idempotent and order independent" - 
See [0263]) so that a first function idempotent function may be executed even though 
an equivalent idempotent function has been executed previously ("If this condition is 
met, the semantics of the operations invoked 2060 are such that if events are 
processed in different orders or if the same event is processed more than once, the 
ultimate system state will be identical"- See [0263]). 

It would have been obvious to one of ordinary skill at the time the invention was 
made to use idempotent functions with the distributed computing method taught by '085 
and Paxos for the same reasons as those given with respect to Claim 5. 

4. Claim 38 is rejected under 35 U.S.C. 103(a) as being unpatentable over '085 in 
view of Paxos and further in view of US 2002/01 1 21 98 (hereinafter, '1 98). 

Regarding Claim 38, '085 and Paxos do not explicitly teach the computing 
environment comprising a monitoring device and the failure being detected by a 
monitoring device. However, '198 does teach a monitoring device that detects a failure 
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("At one extreme, the system administrator, operator or a third party (e.g., software for 
monitoring devices) detects a device failure"- See [0058]). It would have been obvious 
to one of ordinary skill in the art at the time the invention was made to include a 
monitoring device within the computing environment taught by '085. Motivation for 
doing so would be to facilitate recovery in the event that a device fails (See paragraph 
[0058] of '198). 

Response to Arguments 

5. Applicant's arguments filed on February 25, 2010 have been fully considered but 
they are not persuasive. 

6. On page 16 of the remarks, Applicant argues in substance that '085 only 
discloses receiving messages from a single client (i.e., a leader) and does not 
disclose receiving messages from a first, second and third client. 

Examiner disagrees. Fig. 1 , for example, in '085 illustrates a plurality of 
computers 12 which are part of a fault-tolerant distributed system ("The invention has a 
number of important features and advantages. It provides a system and method for 
implementing a distributed state machine in which consistency is maintained despite the 
failure of any number of processes and communication paths"- See Col. 1 0, lines 62- 
66; See also Fig. 1). '085 additionally teaches receiving messages from a plurality of 
clients ("One of the processes in the network is designated as a leader, and it sends 
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ballots with proposed commands to the other processes" - See Col. 3, lines 14-16; "If q 
decides to vote for ballot number b, then it sends a Voted(b,q) message to p"- See Col. 
5, lines 8-9) in the form of votes which are sent in response to a ballot issued by a 
leader. 

7. On page 16 of the remarks, Applicant argues in substance that '085 does 
not disclose "using a fault tolerant consensus algorithm." 

Examiner disagrees. In fact, both '085 and Paxos Made Simple disclose the use 
of fault tolerant consensus algorithms in distributed systems. '085 discloses "This 
invention pertains generally to distributed computing systems and, more particularly, to 
a distributed system and method utilizing a state machine approach and having the 
ability to continue working despite the occurrence of a fault such as a processor 
stopping or running slowly, or the loss or duplication of messages between processors." 
(See Col. 1 , lines 8-14). Paxos discloses "The Paxos algorithm for implementing a 
fault-tolerant distributed system" (See p. 1 , para. 1 ). 

8. On page 18 of the remarks, Applicant argues in substance that Paxos does 
not disclose a first message comprising a first client identifier , a second message 
comprising a second client identifier and a third message comprising a third 
client identifier . 
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Examiner disagrees. With respect to the claimed feature of the first, second and 
third client identifiers, the '085 reference was relied upon. '085 discloses "In a 
distributed system, two or more data processing systems or computers are connected 
together in a network in which the processors or computers can send messages to each 
other and processes can be distributed among the processors or computers" (See Col. 
1 , lines 1 5-1 9). '085 further states "The selection requirement is then satisfied by 
having one of the processes send a message containing its identification number to 
every other process" (See Col. 8, lines 35-37). According to the broadest reasonable 
interpretation, the term "client" may refer not only to a device, but also to software (i.e., 
applications) executed by a device. The client identifiers disclosed by '085 take the 
form of process identification numbers, where the processes are software that is 
executed by the computers in the distributed system. 

Allowable Subject Matter 

9. In the previous office action dated 1 1/25/2009, Claims 7 and 17 were both 
objected to as being dependent upon a rejected base claim, but would have been 
allowable if rewritten in independent form including all of the limitations of the base 
claim and any intervening claims. Applicant cancelled Claims 6, 7, 16 and 17, but did 
not incorporate the features of these claims in there entirety into all of the independent 
claims. The Examiner urges the Applicant to incorporate the full subject matter of the 
cancelled claims into the independent claims in order to place this application in 
condition for allowance. 
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Conclusion 

10. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Scott M. Sciacca whose telephone number is (571) 270- 
1 91 9. The examiner can normally be reached on Monday thru Friday, 7:30 A.M. - 5:00 
P.M. EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jeff Pwu can be reached on (571 ) 272-6798. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



/Scott M. Sciacca/ 
Examiner, Art Unit 2446 

/Jeffrey Pwu/ 

Supervisory Patent Examiner, Art Unit 2446 



